Sie haben das Recht zu schweigen… Rollen und Berechtigungen, ein kleiner Einblick

Immer wieder erreichen uns Nachrichten dass in IT-Systemen von Unternehmen eingebrochen und Daten entwendet wurden. Damit es unauthorisierten Personen nicht leicht gemacht wird können u.a. Rollen und Berechtigungen verwendet werden, gerade im Kontext von Entwicklungen mit Schnittstellen z.B. auf Basis eines Remote Function Call (RFC). Da der Entwickler bestimmt wo, wie oder ob überhaupt Berechtigungen geprüft werden, soll diese Betrachtung das Themengebiet ein wenig beleuchten und Sensibilität schaffen.

Im Fokus eines Entwicklers steht primär die Funktionalität. Daneben muss er auf die Architektur und das Design achten sowie Konventionen und Vorgehensweisen verfolgen. Berechtigungsaspekte stehen selten im Fokus, oftmals nur ein Satz in der Anforderung, wenn überhaupt. Wie schnell kann es da passieren, dass ein RFC-fähiger Funktionsbaustein ausgeliefert wird der gar keine Berechtigungsprüfung enthält. Nun könnte man an dieser Stelle entgegnen dass bei einem RFC-Aufruf standardmäßig das S_RFC-Berechtigungsobjekt geprüft wird, egal ob eine Berechtigungsprüfung enthalten ist oder nicht. Das ist richtig, jedoch beinhaltet diese Prüfung nur den Aspekt ob ein RFC-fähiger Funktionsbaustein auch via RFC durch den Benutzer aufgerufen werden darf. Dabei ist es egal um welchen Baustein es sich handelt und welchen Inhalt er liefert. Dies führt uns deutlich vor Augen, wie wichtig eine Berechtigungsprüfung in diesem Zusammenhang ist.

Grundvoraussetzung für den Zugriff auf ein System ist das Vorhandensein eines Benutzers, mit Benutzerkennung und Passwort. Jedem Benutzer werden Rollen und damit Berechtigungsprofile zugeordnet.

Die Berechtigungen eines Benutzers werden in der Regel nicht direkt, sondern in Form von Berechtigungsprofilen zusammengefasst. Eine Berechtigung ist eine Ermächtigung, eine bestimmte Aktion im System durchzuführen. Dies geschieht auf der Grundlage einer Gruppe von Werten für die einzelnen Felder eines Berechtigungsobjekts. Berechtigungsobjekte ermöglichen eine an mehrere Bedingungen gebundene Prüfung einer Berechtigung.

Im Programm wird durch die Verwendung der entsprechenden Syntax ermittelt, ob der Benutzer eine ausreichende Berechtigung für eine bestimmte Aktivität hat, indem die im Programm vorgegebenen Feldwerte für das Berechtigungsobjekt mit den in den Berechtigungen des Benutzerstammsatzes enthaltenen Werten verglichen werden.

Ein Beispiel:
Authority-Check Object ‘Z_TEST’
  Id ‘ACTVT’ Field ’16’.

If sy-subrc <> 0.
  Exit.
EndIf.

Hier wird das Berechtigungsfeld ACTVT (Aktivität) des Berechtigungsobjektes Z_TEST geprüft. Ist der Feldwert 16 dem verwendeten Benutzer zugeordnet, so ist der Systemrückgabewert (sy-subrc) gleich 0, andernfalls wird der Verarbeitungsblock verlassen.

Wenden wir uns nun einem praktischem Beispiel zu. Zur Anlage eines Berechtigungsobjektes rufen wir die Transaktion SU21 (Pflege der Berechtigungsobjekte) auf. Zuerst legen wir eine Berechtigungsobjektklasse an, in der Berechtigungen gruppiert werden können.

Nun legen wir das Berechtigungsobjekt an.

Wir weisen dem Berechtigungsobjekt ein Berechtigungsfeld zu und die zulässigen Aktivitäten (Werte).

Als nächstes rufen wir die Transaktion PFCG (Rollenpflege) auf und legen eine neue Einzelrolle an.

Wir aktivieren den Reiter Berechtigungen und legen ein neues Berechtigungsprofil an.

Dann ändern wir die Berechtigungsdaten, wählen keine Vorlage aus und nehmen die manuelle Auswahl eines Berechtigungsobjektes vor. Wir ordnen die gewünschte Aktivität zu, sichern und generieren.

Nun springen wir zurück, wechseln in den Reiter Benutzer und ordnen den oder die gewünschten Benutzer zu.

Zu guter letzt können wir nun das Berechtigungsobjekt abfragen.

Hinweis: Dieser Beitrag zeigt nur einen kleinen Teil der Möglichkeiten und soll, wie eingangs erwähnt, für das Thema sensibilisieren. Weiterhin soll er die Zusammenhänge von Rollen und Berechtigungen transparenter machen und aufzeigen wie “einfach” diese im Kontext einer Entwicklung verwendet werden können.